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(54) A platform independent object and object viewer loader and method 

(57) A class loader downloads objects and object 
viewers from remote computer nodes, and invokes 
locally stored object viewers to view objects. When a 
user selects an object to view, a conventional download- 
ing of the referenced object is initiated. The class loader, 
however, utilizes data type information received at the 
beginning of the object downloading process to deter- 
mine if a viewer for the referenced object is available on 
the users workstation. If an appropriate view is not 
locally available, the class loader automatically locates 
an appropriate viewer on the server from which the 
object is being downloaded, or from any other appropri- 
ate server known to the user's workstation. The class 
loader downloads the located viewer and then invokes a 
program verification procedure to verify the integrity of 
the downloaded viewer before the viewer is executed. 
Once a viewer has been verified, the viewer is added to 
the user's local viewer library, downloading of the refer- 
enced object is completed, and execution of the viewer 
to view the downloaded object is enatiled. If an appro- 
priate viewer cannot be located, or the only viewer 
located does not pass the verification procedure, down- 
loading of the referenced object is aborted. 
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Description 

BACKGROUND OF THE INVENTION 
1. Field of the Invention 




J^' '"""'t" ^'""'"^ '° "^^ °' °" '""NiPle coaputer plartorTO which use 

2. Prior Art 

As represented generally in Figure 1. in a typical prior art networked computer system 100 a first romnnto, mo 
may dawr.,oad a computer program 103 residing on a second corrputer l04Tnts ex^m^I L^^^^^^^ 
r5 W.I. typ.cally be a user workstation having a central proces^ng unit 106. a user interface 108 pr ™em^y UO 

"r '° ^'^"•^^ software from one computer ,o anoTerconce^i tranZ^na 

conquer softwarebetween computer platforms which use distinct .nderlyir,g marine 

lJZ7r'^7^ ^ r automated software verrfication toots far enabling redpients of such 

or ^^^^^^^^^^ °' ^""^^"^"^ ^'^^^^"^ -^are obtained fr:'m rnXTser'er 

Another aspect of the present invention concerns methods for automatically, after a user selects an obiect or f il^ t« 

Th'' '^^""''"9 •'yP^^""'' ^^'^O"- response .0 selection of a h^erlin^ the u^r s WeSTccl 

'e'erenced document oVobie^resWef Ls^c^t^ S 
data embedded in the hyperlink in the document or obiect currentiv beino viewed) and rinirLn. *! . 

program, the user w.11 be unable to view or othen«se utilize the downloaded document 

bv inTinn fhlT!r'- f*' """^ '° '"^"^"y a viewer for the downloaded document or obiect 

by looking through libraries of programs on the server from which the document or ottect was retr^^^ on 

then execute it so as to view the previously downloaded object. However there are some Iic^n,.!^Tll 
f^^:ated«,hexecutingaviewerofunknownorigin.Fo,instance.thedotnlored^^^^^^^ 

resources and/or destroy information on the user s computer, contrary to the user s wishes The plent i^^^Ln 
comesthesedifficultiesbyprovidingaulomaticdownloading Of viewers lor documentsTn^^il^K^^^^ 
verification Of those programs before the do-wnloaded viev^er can b^ex^u^^^ 

55 SUMMARY OF THE INVENTION 

The present invention is a "class loader" tor retrieving (i.e.. downloading) objects and obiect viewers from r.nv,.» 
computer nodes, and for invoking locally stored object viewers to view obje«s. vCa^eTs^e^^n^^.l ^ 
.uch as by using the hyperlink featureof the world W-KieWeb.aca,ven,iLald^Toad^^^^^^^ 
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initiated. The class loader of the present invention, however, utilizes data type information received at the beginning of 
the object downloading process to determine whether a viewer for the referenced object is availatjie on the user's work- 
station. 

If an appropriate viewer is not locally available, the class loader automatically locates an appropriate viewer on the 
server from which the object is being downloaded, or from any other appropriate server known to the user's workstation. 
The class loader downloads the located viewer and then invokes a program verification procedure to verify the integrity 
of the downloaded viewer before the viewer is executed. Once a viewer has been verified, the viewer is added to the 
user's local viewer library, downloading of the referenced object is completed, and execution of the viewer to view the 
downloaded object is enabled. 

If an appropriate viewer cannot be located, or the only viewer located does not pass the verification procedure, 
downloading of the referenced object is aborted. 

The present invention verifies the integrity of computer programs written in a bytecode language, to be commercial- 
ized as the OAK language, which uses a restricted set of data type specific bytecodes. Alt the available source code 
bytecodes in the language either (A) are stack data consuming bytecodes that have associated data type restrictions 
as to the types of data that can be processed by each such bytecode. (B) do not utilize stack data but affect the stack 
by either adding data of known data type to the stack or by removing data from the stack without regard to data type, or 
(C) neither use stack data nor add data to the stack. 

The present invention provides a verifier tool and method for identifying, prior to execution of a bytecode program, 
any instruction sequence that attempts to process data of the wrong type for such a bytecode or if the execution of any 
bytecode instructions in the specified program would cause underflow or overflow of the operand stack, and to prevent 
the use of such a program. 

The bytecode program verifier of the present invention includes a virtual operand stack for temporarily storing stack 
information indicative of data stored in a program operand stack during the execution a specified bytecode program. 
The verifier processes the specified program by sequentially processing each bytecode instruction of the program, updat- 
ing the virtual operand stack to indicate the number, sequence and data types of data that would be stored in the operand 
stack at each point in the program. The verifier also compares the virtual stack information with data type restrictions 
associated with each bytecode. instruction so as to determine whether, during program execution, the operand stack 
would contain data inconsistent with the data type restrictions of the bytecode instruction, and also determines whether 
any bytecode instructions in the specified program would cause underflow or overflow of the operand stack. 

To avoid detailed analysis of the bytecode program's instruction sequence ftow, and to avoid verifying bytecode 
instructions multiple times, all points (called multiple-entry points) in the specified program that can be can be immediately 
preceded in execution by two or more distinct bytecodes in the program are identified. In general, at least one of the two 
or more distinct bytecodes in the program will be a jump/branch bytecode. During processing of the specified program, 
the verifier takes a "snapshot" of the virtual operand stack immediately prior to each multiple-entry point (i.e.. subsequent 
to any one of the preceding bytecode instructions), compares that snapshot with the virtual operand stack state after 
processing each of the other preceding bytecode instructions for the same multiple-entry point, and generates a program 
fault if the virtual stack states are not identical. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments 
of the invention and, together with the description, serve to explain the principles of the invention, wherein: 

Figure 1 depicts two computers interconnected via a network. 

Figure 2 depicts two computers interconnected via a network, at least one of which includes a secondary storage 
device for storing multiple copies of a source program in different executable forms. 

Figure 3 depicts two computers interconnected via a network, at least one of which includes a bytecode program 
verifier and class loader in accordance with the present invention. 

Figure 4 represents a flow chart of the loading process for accessing a bytecode program and viewer stored in a 
remote server according to the preferred embodiment of the present invention. 

Figure 5 depicts data structures maintained by a bytecode verifier during verification of a bytecode program in 
accordance with the present invention. 

Figure 6 represents a flow chart of the bytecode program verification process in the preferred entxxiiment of the 
present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

■s intended to cover alternatives niodifiMtinnc =oh , '° '"f*^ emtiodrments. On the contrary, the invention 
'0 .he invention as defined by .7e ap^;^c°ai;^s "^^ «ope o( 

toas^SrZ;™^^ 

node 202 includTs cen^atpr^eSina "^'^"'X 2'6 such as the Internet. The tfrst computer 

(*sc storage, 2,2. a4 rrl^Tr^Torc^.^^^^^^^^^ 
•5 the computer communication network 216 The disc ^oraarLlS n * ""^^ to 

as well as data files and other information ' ' ""^'^^ ^ P'^'^sor 206. 

and a modem or other communication interface 22^1™ conn^s the ^i^n ; ?"''!!''™'' 
!0 nicaiion network 216. The disc storage 224 inclu^rfnl J^T k . - ""^^ '° '"^ ^O"™"" 

orca,a,og,,orloca.ingin,orn^io„redT * 

23. for execution by the processor 2,3 a^^/orS^onToTther ^^^^^^^ 

!5 other. For instance the server no^ 2r'^, K^°c * ' J ^ '"° ""^'^'^ ""'^ ««=uted on the 

.he user workstaton no^r^2 r^y bTan Im com^^^^^^^ computer using a Unix operating system while 

DOSoperating system. Furthen^rrome, serw^^^^ microprocessor and a Miaosoft 
20<mig«useavarie.yo,.^^^^^^ 

0 -rdiS,r.yr;::s^ 

we.l as a plurality of ob^ecTv^^rs p^aT^^^^^ "T"" ° '"'^"^ '■^^ ^"^ ^39) as 

invention, many varied u^rs cTrfbe sup^^ed^m^^^^^^ TT-^TT '"^^ "°«*'«'-,"sing the present 

Referring now to Figu^ 3 a S^c^™.^~ , T^°" °' ' ""^'^ ^^^^ °' P'°9'am. 

is showr,. Alirs. conplr node 2^ ^lt™ra ™ 

neNvork 268 such asThe In.erne. Aoa n ius. a^ifth! t„ T"' ^ ^"^""^^ communicaUons 

u.i.izedi..eren. computer pllrla^oi^^lunV''^^^^^ 

one of the two computer nodes cannot e^^l^t^ li^^a^ ""^"^^ °" 

Microsystems conputer using a SerlttioTs^m J,i,.?H T""' '"'"^^ ^54 might be a Sun 

computer usinganlo486miJoproJ3a,^rMicrror^^^ 
with Figure 2. ^e firs. compZn^elK'n^lllTc^^^^^ 
(RAM, 260. secondary mX S «f"e^^^^^ 

.he first computer node 252 t7the Vol™ . communication interface 264 that connects 

execution bTtt-e pr^e^' 257 a! ^^'^T.""T^ ^""'^^ ^'"^ P^^rams lor 

purposes of this descXn « w^ ^ a Jum^^Mh! f '"'^'^ '^'^ °' the 

from the second co^X noder«^are c^™l^^^^^ ""^^ ^^^'^^^ P'Pfl'am 267 

ingreaterd«ai,bZ?co?unJ^;:i^;',b1X 

imer;:::X::!,tn"tf;S ^2;^,:^:^^^^^ ? r conp-,ed or 

OAK instruction set is P^ovwJ^in T^T^he oS^^^^ I " instructions in the 

data type specSic. Spe^fically. the oZk nsta/etton set dte^nn^^^^^ charaaenzed by bytecode instructtons that are 

types by des.gnatingseparateopcodes.rSy aX^C^^^^^ 

perform the same basic function ^for oYamr^^a t ^ " Djnecoaes are included withm the instruction set to 
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utilizes data in a manner consistent with the data type specific instructions in the OAK instruction set will not violate the 
integrity oi a user s computer system. 

In the preferred embodiment, the available data types are integer, long integer, short integer (16 bit signed integer), 
single precision floating point, double precision floating point, byte, character, and object pointer (sometimes herein 
called an object reference). The "object reference* data type includes a virtually unlimited number of data subtypes 
because each "object reference" data type can include an object class specHication as part of the data type. In addition, 
constants used in programs are also data typed, with the available constant data types in the preferred embodiment 
comprising the data types mentioned above, plus class. fiekJref, methodref. string, and Asciz. all of which represent two 
or more bytes having a specific purpose. 

The few bytecodes that are data type independent perform stack manipulation functions such as (A) duplicating one 
or more words on the stack and placing them at specific locations within the stack, thereby producing more stack items 
of known data type, or (B) clearing one or more items from the stack. A few other data type independent bytecode do 
not utilize any words on the stack and leave the stack unchanged, or add words to the stack without utilizing any of the 
words previously on the stack. These bytecodes do not have any data type restrictions with regard to the stack contents 
prior to their execution, but all modify the stack's contents in a totally predictable manner with regard to the data types 
of the items in the stack. As a result, the number of operands in the stack and the data type of all operands in the slack 
can be predicted (i.e.. computed) with 100% confidence at all times. 

The second computer node 254. assumed here to be configured as a file or other information sen/er. includes a 
centra! processing unit 268. a user interlace 270. primary memory (RAIV1) 272. secondary memory (disc storage) 274. 
and a modem or other communication interface 276 that connects the second computer node to the computer commu- 
nication network 266. The disc storage 274 is comprised of a directory 280. objects 282 including a first object 283. a 
viewer library 284 and programs 286 for execution by the processor 258 and/or distribution to other computer nodes, at 
least one of which is the bytecode program 267 for transfer to computer node 252. 

As shown in Figure 3. the first computer node 252 stores in its secondary memory 262 a class loader program 296 
for retrieving (i.e.. downloading) objects and object viewers from other computer nodes, and for invoking locally stored 
object viewers to view objects. The class loader 296 also automatically verifies (at the site of the end user's workstation 
node) downloaded object viewers to verify the integrity of each viewer before it is executed by each user. 

For the purposes of this document, an "object" thsi may be "viewed" using an associated viewer can be either (A) 
a data-only type of object, such as a file other data structure that contains data of a specific type or format, such as 
JPEG. GIF. MPEG, or lvtPEG2 data, without having any embedded method or software, or (B) a method-storing object, 
such as a file or other data structure that includes one or more embedded methods, and optionally data as well. For 
instance, distinct viewers may be needed for viewing data-only objects that store distinct image data types, such as 
JPEG and GIF. and for viewing data-only objects that store distinct video program data types such as MPEG and MPEG2. 
Other examples might be distinct viewers for viewing charts of data, viewers with built-in data decryption software for 
viewing encrypted data (when the decryption key is known to the user), and so on. 

In addition, distinct viewers may be needed for method -storing objects using different internal program types. For 
instance, difterent internal program types in various method -storing objects might use distinct scripting languages or 
might assume the availability of different libraries of utility programs, thereby requiring different viewers. 

A "viewer" (sometimes called an interpreter) decodes data and/or instructions in a specrtied object and generally 
performs whatever computations and operations are needed to make objects of a particular data type or class usable. 
In the present invention, such object viewers are bytecode programs, written in a source code bytecode language so 
that the integrity of each object viewer can be independently verified by an end user through execution of a bytecode 
program verifier 240. Bytecode program verification is discussed in more detail below. 

It should be noted that a distributed computer system 250 may include platform independent object viewers in 
accordance with the present invention as well as other object viewers which are not platform independent and which 
cannot be verified using the bytecode program verifier 240 and class loader 296 tools of the present invention. In such 
a hybrid system, the automated viewer integrity verification benefits of the present invention will be provided for bytecode 
viewer programs, but not for other viewer programs. 

The class loader 296 is an executable program for loading and verifying objects and object viewers from a remote 
server. When reviewing a document on the internet's World Wtde Web (WWW) for example, a page of the document 
may contain references to other documents or to objects. A user can access such other documents or objects by selecting 
a given object via an associated hyperlink. Such selection is usually performed by a user, in conjunction with a graphical 
user interface on a workstation node, by depressing a button on a pointer device while using the pointer device to point 
at a graphical image representing the hyperlink selection. 

During the selection process, the document or object which is currently being viewed may contain references to 
other documents or objects, including some having a data type which is unknown to the user's workstation. The dass 
loader of the present invention is utilized to both locate a viewer associated with a "foreign" data type, and to verify 
program integrity of all downloaded bytecode programs prior to their execution by the user. 
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viewer l.brary 298 .n its own local storage 262. Secondly, if the class loader can not locate th^^^Z^ 
executes a search routine at both the source server and othpr corw^l -.^ . aPPropnate wewer. it 

5 proper viewer. 1^ no viewer can be i^^m^^^^^^^^^ 

.he dass loader pZ^^^LeS^rJ^ T^l^ T^- ^""^ ' ' pseudocode representation of 
computer language convention s'^^eTe pst^^^^X^^^^^^ '^r^ -'"^ un.ersa, 

se,ve?257wTi h ^n n:,:;;:^^^^,^,^,''"^^^^^^^ P-«- opening ,304) a c»nnec«on to a 

o^iroT--™~ 

^ ^-ticnconcerningpropeJ^t-r:^-^^^^^ 
user^^^teTS^iSra^^r^^^^^ 

0 .ype^SSt" : u",a~ r^lLt^ ' '"^'"""^ "'^ -'-^^ <" ^ data 

240isanexecu.ab!epSrrw iZS^^^^^ 

bytecode (source) program prior to m7«"SHhl h!?t^^ 

If stens 3nfl^,nH -5 accepted the downloaded viewer is deleted (320). 

theus^Torfs^:^'^,^ 1°^^^^ 

orrenx>.euserworks,ator(eraMZslrv^^^^^^ Tf." "^^^'^ "'""="^« ""^^^ 'Hes 

again to Figure 3 a second ^^er Sat^s shZ nr?l ' '<"°«"'o"'«"ser's workstation (steps 322 and 323). Referring 

appropriate^eweryS^t'edTt^^'^r^^^^^ 

verifies ttie viewer program accordino to steos 3is ^ . 7 ' ^ "'^ "^^^ downloads and 

servers until all knL ,esour«st7e °hSof an ™^ 
viewer canbe located, d^loadingo'th^^^^^^^^ 
user «,a, a .ewer for the referenc^ 

As indicated above, in the event an appropriate obiect viewer wa< airaaHu • 
user-s workstation (308) orwassuccessfullv^d^Lfoa^J^veT^^^^^^ 
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the selected object is completed (310). If the downloaded object includes one or more embedded bytecode programs 
(330 and is therefore a method-storing object, the bytecode programs in the downloaded object are verified (332) by 
invoking execution of the bytecode verifier on those embedded programs. If the verifier generates a "success" return 
code after processing the embedded programs (334), then the downloaded object is viewed with the associated object 
J viewer (335). If the verifier aborts its processing of the embedded program due to detection of a program that does not 
conform to the verifier's requirements (334). the downloaded object is deleted (336) and an appropriate user message 
is generated. 

In the event that the downloaded object does not include embedded bytecode programs (330), steps 332-334 are 
skipped and the object is viewed with the appropriate viewer (335). 

10 Referring again to Figure 3. the first computer node 252 also stores in its secondary memory 262 a bytecode verifier 
program 240 for verifying the integrity of specified bytecode programs and a bytecode interpreter 242 for executing 
specified bytecode programs. Alternately, or in addition, the first computer node 252 may store a bytecode compiler 244 
for converting a verified bytecode program into an object code program for more eHicient execution of the bytecode 
program than by the interpreter 242. 

15 The bytecode verifier 240 is an executable program which verifies operand data type compatibility and proper stack 
manipulations in a specified bytecode (source) program prior to the execution of the bytecode program by the processor 
257 under the control of the bytecode interpreter 242 (or prior to compilation of the bytecode program by compiler 244). 
Each bytecode program 267 (including the downloaded object verifier) has an associated verification status value 302 
that is initially set to False when the program is downloaded from another location. The verification status value 302 for 

20 the program is set to True by the bytecode verifier 240 only after the program has been verHied not to fail any of the data 
type and stack usage tests performed by the verifier 240. 

The Bytecode Program Verifier 

25 Referring now to Figure 5. the execution of the bytecode program verifier 240 will be explained in conjunction with 
a particular bytecode program 340. The verifier 240 uses a few temporary data structures to store information it needs 
during the verification process. In particular, the verifier 240 uses a stack counter 342, a virtual stack 344. a virtual local 
variable array 345. and a stack snapshot storage structure 346. 

The stack counter 342 is updated by the verifier 240 as it keeps track of the virtual stack manipulations so as to 
30 reflect the current number of virtual stack 344 entries. 

The virtual stack 344 stores data type information regarding each datum that will be stored by the bytecode program 
340 in the operand stack during actual execution. In the preferred embodiment, the virtual stack 344 is used in the same 
way as a regular stack, except that instead of storing actual data and constants, the virtual stack 344 stores a data type 
indicator value for each datum that will be stored in the operand stack during actual execution of the program. Thus, for 
35 instance, if during actual execution the stack were to store three values: 
HandleToObjectA 
5 
1 

the corresponding virtual stack entries will be 
40 R 

I 

where "R" in the virtual stack indicates an object reference and each "I" in the virtual stack indicates an integer. Further- 
more, the stack counter 342 in this example would store a value of 3. corresponding to three values being stored in the 
4S virtual stack 344. 

Data of each possible data type is assigned a corresponding virtual stack marker value, for instance: integer (I), 
long integer (L). single precision floating point number (F). double precision floating point number (D). byte (8). short 
(S). and object reference (R). The marker value for an object reference will often include an object dass value (e.g.. 
R:point. where "point" is an object class). 

50 The virtual local variable array 345 serves the same basic function as the virtual stack 344. That is. It is used to 
store data type information for local variables used by the specified bytecode program. Since data is often transferred 
by programs between local variables and the operand stack, the bytecode instructions performing such data transfers 
and otherwise using local variables can be checked to ensure that the local variables accessed by each bytecode instruc- 
tion are consistent with the data type usage restrictions on those bytecode instructions. 

55 in operation, the verHier 240 processes each bytecode instruction which requests datum to be popped off the stack 
and pops off the same number of data type values off the virtual stack 344. The verifier then compares the "popped" 
data type values from the virtual stack 344 with the data type requirements of the bytecode instruction. Similarly, for 
each bytecode instruction requesting datum to be pushed onto the stack, the verifier pushes onto the virtual stack a 
corresponding data type value. 
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One aspect of program vertotion .n accordance with present invention is verificaoon .hat the number and da,:, 
type oftne operands m the operand stack status is identical every time a particular instruction is exelT^ a r^nin^ 
bytecode .nstruction can be immediately preceded in execution by two or more difter^ "^0^^1,1^^ 
s.acks,a.us,,m,edi«elya,ter processing 0, each oltho^ 

ab^e frlr^Lf '"^ **" " "^"^^ oncorxiitional iump or branch ir^uction A^' ^ o me 

above stack cor^stency requirement .s that ea* program loop must not result in a net addition or reductTon 
number of operands stored in the operand stack. auu'uon or reouction m the 

344 '° -snapshots- of the stack counter 342 arxJ virtual stack 

.'o,,he,rm "'^'"'^"'■-'^^''^^^ 
SC. OTl. DT2. DT3 DTn 

where SC is the stack counter value. OTi is the first data type value in the virtual operand stack 0T2 is the second d^t^ 

trratrr"^^^^ 

^'^^ ^"^''0' s'orage structure 346 is bifurcated into a direaory portion 348 and a snarKhm ..„r=.„o ~, .■ 
350. ^e directory portion 348 is used to store target instruction identrtiers^e^. me aSoMe o relS^e /cS !L ^^^^^^^ 

-Target- instructions are defined to be all bytecode instructions that can be the destination of a ^ h,.~.>, 
,nstruct,on. For example, a conditional branch instruction includes a condition (which rnay or not b^^i^ 
a branch ,nd.cat,ng to which location (target) in the program the execution is to "jump- in thTeTent me cfndlLr 
satisfied, in evaluating a conditional jump instruction, me verifier 240 utilizes the stickti^sholtlorltt ? ^.c 
to store bom the identity of the targe, location (in me directory portion 348) and the '.^uroTtbe i^^^^^^ 
snapshot portion 350) jus. before the junp. The operation of me stack snapshot storage sruc^re r46 ex„ 1^ 
■n greater detail below in conjunction ™m me description of me execution of me byteci^e ve*' pm^^^^^^ 

As was descnbed pre«ously. me bytecode program 340 includes a plurality of data t»e »SsJ^ctiW 
0 Which ,s evaluated by me verifier 240 of the present invention. The t^ecode progrlSnl^^s for 
stack manipulations 352 and 354 (push integer onto the steck and pop Neger from thTs^ r«~2J^v> , Z 
lump 356 and its associated target 364. a backwards junp 366 and i^ lssS^^Z!li3^,^^^\fJZ"'^. 

Since me verrfier 240 of the preferred embodiment of the present invention only seeks to verify sta^k r^S^^ 
da^^^typecompatibilities, me operation otmebytecodeverifier can be explain^usingthisr^^^^^^^ 



in detail. Appendix 2 lists a pseudocode representation of me verifier program The pseudo^e usl in , 
essentially a compuler language using universal computer language conven.ions'^hl^'pseS:^^::^;^"' 

ct^^r X^l^'ln^ar "^^^ °' " "'^"^ '° ^ ^'^ ^L^Tl^S 

As Shown in Figure 6A. me downloaded bytecode program is loaded (400) into the bytecode verifier 240 for process- 

and ^''^^n '^r"^ '^"^ ^"^^"^ '^'^ '° '-^^^ '"fof-^tion associated with conditional 

After all the rnstructions in the program have been processed, the directory 348 is preferabiy sorted f420^ tn o.h th. 
target locations noted in the directory in address sequential order P^ereraay sorted (420) to put the 

.ith llt'.'"^ ^' ^""^ ^'^^^ ^"^PS^^ot storage structure 346 has been loaded 
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Referring now to Figure 68. a second pass through the bytecode program is initiated in order to verify proper use 
of the operand stack and of data types by the bytecode progrann. The first instruction of the bytecode program Is selected 
(430) and the verifier first checks (432) to see if the address for the selected instruction has been stored in the directory 
portion 348 of the stack snapshot storage structure 346 in the first pass described above. 
5 If the address of the selected Instruction is in the directory 348. indicating that the selected instruction is the target 

of a conditional or un -conditional jump, the verifier checks (434) to see if an associated stack snapshot has been stored 
in the snapshot portion 350 of the stack snapshot storage structure 346. If a stack snapshot has not been stored (indi- 
cating that the instruction is a target of a backward jump), then the contents of the virtual stack and the stack counter 
are stored (436) in the stack snapshot storage structure 346. The snapshot contains information on *u^e status of the 
10 virtual stack just before the execution of the instruction being processed, including a data type value for each datum that 
has been pushed onto the stack. The verifier will then continue the verification process and analyze the individual instruc- 
tion, starting at step 450. as described below. 

If a stack snapshot has been stored for the currently selected instruction (indicating that a jump instruction associated 
with this target instruction has already been processed), then the verifier compares (438) the virtual stack snapshot 
J5 information stored in the snapshot portion 350 of the stack snapshot storage structure 346 for the currently selected 
instruction with the current state of the virtual stack. If the comparison shows that the current state and the snapshot do 
not match, then an error message or signal is generated (440) identifying the place in the bytecode program where the 
stack status mismatch occurred. In the preferred embodiment, a mismatch will arise if the current virtual stack and 
snapshot do not contain the same number or types of entries. The verifier will then set a verification status value 245 
20 for the program to false, and abort (442) the verification process. Setting the verification status value 245 for the program 
to false prevents execution of the program by the bytecode interpreter 242 (Figure 3). 

if the current virtual stack and the stored stack snapshot for the current instruction match (438). then the verifier will 
continue the verification process and analyze the individual instruction, starting at step 450. as described below. 

If the address of the currently selected instruction is not found within the directory portion 348 of the stack snapshot 
25 storage structure 346 or if a stack status mismatch is not detected, then the verifier performs selected ones of a series 
of checks on the instruction depending on the particular instructions stack usage and function. 

Referring to Figure 6C. the first check to be performed concerns instructions that pop data from the operand stack. 
If the currently selected instruction pops data from the stack (450). the stack counter is inspected (452) to determine 
whether there is sufficient data in the stack to satisfy the data pop requirements of the instruction. 
30 If the operand stack has insufficient data (452) for the current instruction, that is called a stack underflow, in which 
case an error signal or message is generated (454) identifying the place in the program that the stack underflow was 
detected. In addition, the verifier will then set a verification status value 245 for the program to false, and abort (456) the 
verification process. 

If no stack underflow condition is detected, the verifier will compare (458) the data type code information previously 

35 stored in the virtual stack with the data type requirements (if any) of the currently selected instruction. For example, if 
the opcode of the instruction being analyzed calls for an integer add of a value popped from the stack, the verifier will 
compare the operand information of the item in the virtual stack which is being popped to make sure that is of the proper 
data type, namely integer. If the comparison results in a match, then the verifier deletes (460) the information from the 
virtual stack associated with the entry being popped and updates the stack counter 342 to reflect the number of entries 

*o popped from the virtual stack 344. 

If a mismatch is detected (458) between the stored operand information in the popped entry of the virtual stack 344 
and the data type requirements of the currently selected instruction, then a message is generated (462) identifying the 
place in the bytecode program where the mismatch occurred. The verifier will then set a verification status value 245 
for the program to false and abort (456) the verification process. This completes the pop verification process. 

45 Referring to Figure 60. if the currently selected instruction pushes data onto the stack (470), the stack counter is 
inspected (472) to determine whether there is sufficient room In the stack to store the data the selected instruction will 
push onto the stack. If the operand stack has insuffictent room to store the data to be pushed onto the stack by the 
current instruction (472). that is called a stack overflow, in which case an error signal or message is generated (474) 
identifying the place in the program that the stack overflow was detected. In addition, the verifier will then set a verification 

50 Status value 245 for the program to false, and abort (476) the verification process. 

If no stack overflow condition Is detected, the verifier will add (478) an entry to the virtual stack indicating the type 
of data (operand) which is to be pushed orrto the operand stack (during the actual execution of the program) for each 
datum to be pushed onto the stack by the currently selected instruction. This information is derived from the data type 
specific opcodes utilized in the bytecode program of the preferred embodiment of the present Invention. The verifier also 

55 Updates the stack counter 342 to reflect the added entry a entries in the virtual stack. This completes the stack push 
verification process. 

Referring to Figure 6E. if the currently selected instructkm causes a conditional or uncordltional jump or branch 
forward In the program beyond the ordinary sequential step operation (step 480) the verifier will first check (482) to see 
if a snapshot for the target location of the jump instruction is stored in the stack snapshot storage structure 346. tf a 
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55 



500 (Figure 6F) aetected at step 486. then the verrf.er continues processing at step 

If the currently selected instruction reads data from a local variable (510) Ihe verifier will cn™^. .h - . 

T^:TrT rr ^'""^ "^^ c-esponding virtual Iccil valine ^^iZ^ 'rS^J^^t'^ 
any) of the currently selected rnstruction. If a misrnatch is delected (512) betwPBn .ho ri=., , . "^equfemenls (.( 

data type information in me virtual local variable with the da a typeVs^ a,^ Jilh^^^^^ 

instruction (524) If a mismatch is dPiBrtort (■;9j> h«k .u !. associated with the currently seleaed bytecode 
Bytecode Interpreter 
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If the verifier returns a "verification failure' value (564). the attempt to execute the specified bytecode program is 
aborted by the interpreter (566). 

If the verifier 242 returns a "Verification Success' value (564), the specified bytecode program is linked (568) to 
resource utility programs and any other programs, functions and objects that may be referenced by the program. Such 
a linking step is a conventional pre-execution step in many program interpreters. Then the linked bytecode program is 
interpreted and executed (570) by the interpreter. The bytecode interpreter of the present invention does not perform 
any operand stack overflow and underflow checking during program execution and also does not perform any data type 
checking for data stored in the operand stack during program execution. These conventional stack overflow, underflow 
and data type checking operations can be skipped by the present invention because the verifier has already verified that 
errors of these types will not be encountered during program execution. 

The program interpreter of the present invention is espedally efficient for execution of bytecode programs having 
instruction loops that are executed many times, because the operand stack checking instructions are executed only once 
for each bytecode in each such instruction loop in the present invention. In contrast, during execution of a program by 
a conventional interpreter, the interpreter must continually monitor the operand stack for overflows (i.e.. adding more 
data to the stack than the stack can store) and underflows (i.e.. attempting to pop data off the stack when the stack is 
empty). Such stack rronitoring must normally be performed for all instructions that change the stack's status (which 
includes most all instructions). For many programs, stack monitoring instructions executed by the interpreter account 
for approximately 80% of the execution time of an interpreted computed program. As a result, the interpreter of the 
present invention will often execute programs at two to five times the speed of a conventional program interpreter running 
on the same computer. 

The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of 
illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, 
and obviously many modifications and variations are possible in light of the above teaching. The embodiments were 
chosen and described in order to best explain the principles of the invention and its practical application, to thereby 
enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are 
suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended 
hereto and their equivalents. 
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TABLE 1 

BYTECODES IN OAK LANGUAGE 



INSTRUnTlON r^^Mp 

aaload 

aastore 

aconsLnulI 

aload 

a return 

arraylength 

astore 

astore_<n> 

athrow 

bipush 

breakpoint 

catchsetup 

catchteardown 

checkcast 

df2 

621 
d2l 

dadd 
daload 
dastore 
dcmpg 

dcmpi 

dconst_<d> 

ddiv 

dioad 

dload_<n> 

dmod 



SHORT nF.qrniPTioN 



load object reference from array 

store object reference into object reference array 

push null object 

load local object variable 

return object reference from function 

get length of array 

store object reference into local variable 

store object reference into local variable 

throw exception 

push one-byte signed integer 

call breakpoint handler 

set up exception handler 

reset exception handler 

make sure object is of a given type 

convert double floating point number to single 

precision floating point number 

convert double floating point number to integer 

convert double floating point number to long 

integer 

add double floating point numbers 
load double floating point number from array 
store double floating point number into array 
compare two double floating point numbers (return 
1 on incomparable) 

compare two double floating point numbers (return 

•1 on incomparable) 

push double floating point number 

divide double floating point numbers 

load double floating point number from local 

variable 

load double floating point number from local 
variable 

perfomn modulo function on double floating point 
numbers 
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^"^u* multiply double floating point nunnbers 

^"®g negate double floating point number 

^''^^um return double floating point number from function 

^store store double floating point number into local 

variable 

dstore_<n> store double floating point nt^nber into local 

variable 

*^sub subtract double floating point numbers 

dup duplicate top stack word 

clup2 duplicate top two stack words 

dup2_x1 duplicate top two stack words and put two down 

dup2_x2 duplicate top two stack words and put three down 

*^'JP-^"' duplicate top stack word and put two down 

dup_x2 duplicate top stack word and put three down 

convert single precision floating point number to 

double floating point number 

convert single precision floating point number to 

integer 

^21 convert Single precision floating point number to 

long integer 

^^^^ add single precision floating point numbers 

'3'03d load single precision floating point number from 

array 

^^^^ore store into single precision floating point number 

array 

'®"^P9 compare single precision floating point numbers 

(retum 1 on incomparable) 
'®"^P' compare Single precision floating point number 

{return -1 on incomparable) 
fconst_<f> push single precision floating point number 

^d'v divide single precision floating point numbers 

^'°^d load single precision floating point number from 

local variable 

fload_<n> load single precision floating point number from 

local variable 

''^'^d perfomi modulo function on single precision 

floating point numbers 

multiply single precision floating point numbers 
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negate single precision floating point number 
^^^^^^ single precision floating point number from 

function 

store single precision floating point number into 
local variable 

fstore_<n> store single precision floating point number into 

local variable 

'^"^ subtract single precision floating point numbers 

9®f^'®'d fetch field from object 

9^*static set static field from class 

9oto branch always 

convert integer to double floating point number 
convert integer to single precision floating point 
number 

convert integer to long integer 
'^^'^ add integers 

load integer from array 
'^"^ boolean AND two integers 

'^store store into integer array 

iconst_<n> push integer 

iconst_m1 push integer constant minus 1 

integer divide 
if_acmpeq branch if objects same 

if_acmpne branch if objects not same 

if_icmpeq branch If integers equal 

fUcmpge branch if integer greater than or equal to 

lUcmpgt branch if integer greater than 

' -'^^P'® branch if integer less than or equal to 

''-'*^"^P'* branch if integer less than 

if.icmpne branch if integers not equal 

branch if equal to 0 
''9® branch if greater than or equal to 0 

'^9* branch if greater than 0 

branch if less than or equal to 0 
branch if less than 0 
branch if not equal to 0 
""^ increment local variable by constant 

load integer from local variable 
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iload_<n> load integer from local variable 

imod perform modulo function on integers 

imul multiply integers 

ineg negate integer 

instanceof detemnine if object is of given type 

int2byle convert integer to signed byte 

int2char convert integer to char 

invokeinterface invoke interface method 

invokemethod invoke class method 

invokesuper invoke superclass method 

ior boolean OR two integers 

iretum return integer from function 

ishi integer shift left 

Ishr integer arithmetic shift right 

istore store integer into local variable vindex 

istore_<n> store integer into local variable n 

isub subtract integers 

iushr integer logical shift right 

ixor boolean XOR two integers 

jsr jump to subroutine . 

12d convert long integer into double floating point 
number 

1 2f convert long integer into single precision floating 



point number 

convert long integer into integer 

add long integers 

load long integer from array 

boolean AND two long integers 

store into long integer array 

compare long integers 

push long integer constant 

push item from constant pool 

push item from constant pool 

push long or double from constant pool 

divide long integers 

load long integer from local variable 

load long integer from local variable 

perform modulo function on long integers 



12i 

iadd 

laload 

land 

lastore 

Icmp 

lconst_<i> 

Idol 

Idc2 

Idc2w 

Idiv 

Itoad 

lload_<n> 
Imod 
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Imul 
Ineg 

lookupswitch 
lor 

Ireturn 

(shI 

Ishr 

Istore 

lstore_<n> 

Isub 

lushr 

Ixor 

monttorenter 

monitorexit 

new 

newarray 

newfromname 

nop 

pop 

pop2 

putfield 

putslatic 

ret 

return 

saload 

sastore 

siaload 

siastore 

sipush 

tableswitch 

verifystack 



multiply long integers 
Negate long integer 
Access jump table by key match and ' 
boolean OR two long integers 
return long integer from function 
long integer shift left 
long integer arithmetic shift right 
store long integer into local variable 
store long integer into local variable 
subtract long integers 
long integer logical shift right 
boolean XOR long integers 
enter monitored region of code 
exit monitored region of code 
create new object 
allocate new array 
create new object from name 
do nothing 
pop top stack word 
pop top two stack words 
set field in object 
set static field in class 
return from subroutine 
return (void) from procedure 
load signed byte from array 
store into signed byte array 
load unsigned short from array 
store into unsigned short array 
push two-byfe signed integer 
access jump table by index and jump 
verify stack empty 



EP 0 718 761 A1 



APPENDIX 1 
Pseudocode for Class Loader 

User selects an object (the 'referenced objecf) to view. (For example, the 

user selection may be pedormed by selecting a hyperlink to the object 

in a document or other object.) 
Open connection to server storing referenced object. 
Receive handle to referenced object, including data type. 
Check if data type is known to user^s system (i.e., does user have a viewer 

for objects of the received data type) 
If data type is unknown 

{ 

Open second connection to same server 
Request viewer for specified data type: 
If Success 

/• Hybrid System Option: Check for Non-bytecode viewer V 
{ 

If received viewer is not a bytecode program 
{ 

Determine whether or not to accept viewer 
If viewer is not accepted 

Delete received viewer 
Else /• non-bytecode viewer is accepted 7 

Goto FinishObjectDownload 

) 

/• Verification and Registration Procedure 7 
Else 

{ 

Execute Bytecode Verifier on received viewer 
If verification is successful 
{ 

/' Registration of Viewer 7 
Mark received viewer as verified 
Store viewer in local viewer library 
Add data type to list of known data types 
) 

Else 

Delete received viewer 
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If data type is still unknown 
{ 

Search other server sites for viewer for specified data type 
If Success 

^ f^^'"®^«"«<=a«on and registration procedure as above) 

If data type is still unknown 
{ 

Abort downloading of referenced object. 

Inform user that viewer for referenced object cannot be found. 

) 

FinishObjectDownload: /• Branch to this point for non-bytecode viewers V 

Complete downloading of referenced object. 

If downloaded object includes embedded bylecode program(s) 

Execute Bytecode Verifier on embedded program(s) 
If verification is successful 

Mark embedded programs as verified 

Else 



Delete received object 
Abort downloading procedure 
) 

) 

V^w referenced object with viewer for data type associated with referenced 
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APPENDIX 2 
Pseudocode for OAK Bytecode Verifier 

Receive Bytecode Program to be verified. 

Create Virtual Operand Stack Data Structure for storing stack status 
information and Virtual Local Variable Array for storing local variable data 
type information. 

Create data structure for storing Virtual Stack Snapshots. 

First Pass through Bytecode Program: 

Locate ail instructions that are the targets of conditional and 
unconditional jumps or branches (i.e.. can be entered from more than one 
prior instruction). 

Store list of such target instructions in Virtual Stack Snapshot data 
structure. 

Second Pass through Bytecode Program: 
Set VerificationSuccess to Taie 
Do Until Last Bytecode Instruction has been processed: 

Select next bytecode instruction (in sequential order in program) 
If instnjction is in list of target instructions 
{ 

If snapshot of virtual stack for this instruction already exists 
{ 

Compare current state of virtual stack with stored snapshot 
If snapshot does not match current virtual stack state 
( 

Print message identifying place in program that stack 

mismatch occurred 

Abort Verification 

Set VerificationSuccess to False 

Return 

} 

} 

Else 

Store snapshot of current virtual stack status 
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) 

Case(lnstruction Type): 
{ 

Case^Inst.-uction pops data from Operand Stack 
{ 

Check for Stack Underflow 
If Stack has Underflowed 
( 

Print message identifying place in program that 

underflow occurred 

Abort Verification 

Return 

) 

Compare data type of each operand popped from stack with 
data type required (if any) by the bytecode instruction 
If type mismatch 
{ 

Print message identifying place in program that data type 

mismatch occurred 

Set VerificationSuccess to False 

) 

Delete information from Virtual Stack for popped operands 

Update Stack Counter 

) 

Case=lnstruction pushes data onto Operand Stack 

Check for Stack Overflow 
If Stack has Overflowed 
{ 

Print message identifying place in program that overflow 

occurred 
Abort Verification 

Set VerificationSuccess to False 
Return 

} 
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Add information to Virtual Stack indicating data type of data 
pushed onto operand stack 
Update Stack Counter 
} 

Case=lnstruction is a forward jump or branch instruction 
{ 

If snapshot of virtual stack for the target instruction already 
exists 
( 

Compare current stale of virtual stack with stored 
snapshot 

If snapshot does not match current virtual stack state 
{ 

Print message identifying place in program that stack 

mismatch occurred 

Abort Verification 

Set VerificationSuccess to False 

Return 

} 

) 

Else 

Store snapshot of current virtual stack state as snapshot 
for the target instruction; 

} 

Case=Instruction is an end of loop backward jump or other 
backward jump or branch instruction; 
{ 

Compare current virtual stack state with stored snapshot for 
target instruction 

If current virtual stack state does not match stored snapshot 
{ 

Print message identifying place in program that stack 

mismatch occurred 

Abort Verification 

Set VerificationSuccess to False 

Return 
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) 

Case=lnstruction reads data from local variable 
( 

Compare data type of each datum read from bcal variable 
with data type required (if any) by the bytecode instruction 
If type mismatch 
{ 

Print message identifying place in program that data type 

mismatch occurred 

Set VerificationSuccess to False 

} 

} 

Case=lnstruclion stores data into a local variable 
{ 

If corresponding virtual local variable already stores a data 
type value 

{ 

Compare data type value stored in virtual local variable 
with data type of datum that would be stored in the 
corresponding local variable (as determined by the data 
type handled by the current bytecode instruction) 
If type mismatch 
{ 

Print message identifying place in program that data 

type mismatch occurred 

Set VerificationSuccess to False 

) 

} ■■■ • 

Else 

Add information to Virtual Local Variable indicating data 
type of data that would be stored in corresponding local 
variable 

) 
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} /• EndCase '/ 
} /• End of Do Loop V 
Return (VerificationSuccess) 



APPENDIX 3 
Pseudocode for Bytecode Interpreter 

Receive Specified Bytecode Program to be executed 
Call Bytecode Verifier to verify Specified Bytecode Program 
If Verification Success 
{ 

Link Specified Bytecode Program to resource utility programs. 

Interpret and execute Specified Bytecode Program instructions without 
perfomiing operand stack overflow and underflow checks and without 
perfomiing data type checks on operands stored in operand stack. 

) 



A method of operating a distributed computer system having a plurality of distinct computers, the steps of the method 
comprising: 

a) in a lirst computer, storing viewer programs, each viewer program enabling a user thereof to view objects of 

Win'^t^~^uter enabling a user to select a reference to an object located in a second computer: 
c Mid firs^ co^Xr responding to user selection of said reference by establishing a first commun,«fon l,nk 
be^eelilSwrrpier and said second computer and iniSating retrieval of sid object from saKj second 
computer including retrieving data type information associated with said object. ,.^.,„:^„ 
djrsaidlirstcomputer.determining whether said viewer programs stored in sa,d first computer ,ncl^ 

program associated with said retrieved data type; „iri 
e) when said determination in step (d) is negative, determining whether a viewer program associated with said 
retrieved data type is stored in a set of other computers including said first computer: 
0 when said determination in step (e) is positive. 

m loadino a copy of said viewer program associated with said second data type into said lirst computer 
K) ^S-^t^erification proc^ure on said copied viewer program to determine whether sari copied 
viewer program meets predetenrtned operand stack usage cnteria: 

13 W «id determination in step f2 is positive, executing said copied viewer program so as to enable 
said user to view said second object. 
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whether a viewer program associated with said ^n^d^, « ^ ' 5«=°"<«y<Jetermining 
puters. a.« w.en said seeor^ de,er,r.„a:^;^ ^re'^^^^^^ 

associat^SS:^ ^ "'^^ ^'^^ °'^ec, i™,u,ir^ data „pe ir„orn.,ion 
a second computer, including- 

The system o( claim 3, said secorvl computer further including 

smcK u^a":'';:^"'"" '^'^^"^"^ ""'^»'- ^'P^^' .neets predetermined operand 

.0 "^^^'^ - - '° -b.e said user 
predetermined criteria. ^ """"^ ae.erm,nes that said copied viewer program meets said 
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